frontend/src/components/common/CustomButton.tsx (1)

33-33: LGTM! Consider enhancing accessibility further.

The addition of visual feedback for disabled states improves user experience.

Consider adding ARIA attributes for better accessibility:

    <button
-     className={`${btnStyles} ${isDelete ? 'delete-btn' : 'primary-btn'} ${btnDisabled ? 'cursor-not-allowed opacity-50' : ''}`}
+     className={`${btnStyles} ${isDelete ? 'delete-btn' : 'primary-btn'} ${btnDisabled ? 'cursor-not-allowed opacity-50' : ''}`}
+     aria-disabled={btnDisabled}
+     aria-busy={btnLoading}
      disabled={btnDisabled}
      type={btnType || 'button'}
      onClick={btnOnClick}
      form={form}
    >

frontend/src/app/(routes)/multisig/components/common/SignTxn.tsx (1)

Line range hint 64-77: Add error handling for navigation

While the routing logic is clean, consider adding error handling for cases where chainName might be undefined.

Consider this improvement:

  btnOnClick={() => {
    if (isOverview) {
+     if (!chainName) {
+       console.error('Chain name is required for navigation');
+       return;
+     }
      router.push(`/multisig/${chainName}/${address}`);
    } else {
      signTheTx();
    }
  }}

frontend/src/app/(routes)/multisig/components/common/BroadCastTxn.tsx (1)

Line range hint 1-106: Consider adding sequence management feedback

While the component changes support offchain sequence management, consider adding visual feedback to indicate when transactions are queued with different sequences. This would help users understand the state of their transactions in the new offchain sequence management system.

Consider:

1. Adding a sequence indicator near the broadcast button
2. Implementing a tooltip to show the transaction's position in the sequence
3. Adding a warning when broadcasting transactions with potentially conflicting sequences

frontend/src/app/(routes)/multisig/components/multisig-dashboard/RecentTransactions.tsx (1)

Line range hint 1-124: Consider implementing pagination for better scalability

The current implementation loads all transactions in memory and uses slice for display management. As the number of transactions grows, this could impact performance. Consider implementing pagination or virtual scrolling for better scalability.

Some suggestions:

1. Add pagination parameters to the transaction fetching logic
2. Implement infinite scroll or "Load More" functionality instead of loading all transactions at once
3. Consider using a virtualized list component for better performance with large datasets

frontend/src/types/multisig.d.ts (1)

197-197: LGTM! Consider adding JSDoc comments.

The addition of signed_at property aligns well with the PR's objective of implementing offchain sequence management. This timestamp can be crucial for tracking and ordering transactions correctly.

Consider adding JSDoc comments to document the expected timestamp format and purpose:

+ /** ISO timestamp indicating when the transaction was signed. Used for offchain sequence management. */
  signed_at: string;

frontend/src/app/(routes)/multisig/utils/multisigSigning.ts (1)

Line range hint 27-51: Consider concurrent transaction handling

The current implementation might face race conditions in scenarios where multiple transactions are being signed concurrently. Consider:

1. How sequence numbers are allocated when multiple users are signing transactions
2. How to handle sequence conflicts during broadcasting
3. Adding mechanisms to detect and resolve sequence collisions

Consider implementing:

• Sequence number reservation mechanism
• Transaction queue management
• Retry logic for sequence conflicts

frontend/src/app/(routes)/multisig/components/multisig-account/Transactions.tsx (1)

Line range hint 259-271: Effective implementation of sequential broadcast control.

The disableBroadcast={txnsType === 'to-broadcast' && index > 0} logic ensures proper sequence management by:

• Allowing only the first transaction to be broadcasted
• Preventing out-of-sequence broadcasts of subsequent transactions

Consider adding a tooltip or visual indicator to explain why subsequent transactions are disabled. This would improve user experience by making the sequential nature of broadcasting more transparent.

frontend/src/app/(routes)/multisig/components/common/TxnsCard.tsx (2)

43-44: LGTM! Consider adding JSDoc comments.

The new props are well-typed and align with the sequence management requirements. Consider adding JSDoc comments to document their purpose and usage.

+ /** Flag to disable broadcast functionality */
  disableBroadcast?: boolean;
+ /** Flag to indicate if the card is being rendered in overview mode */
  isOverview?: boolean;

Also applies to: 54-55

---

313-318: Consider enhancing the delete confirmation message.

While the warning about re-signing is helpful, consider making it more specific about which transactions will need re-signing.

-        description={
-          'Are you sure you want to delete the transaction?' +
-          (isReadyToBroadcast()
-            ? ' This action will require re-signing any already signed subsequent transactions.'
-            : '')
-        }
+        description={
+          'Are you sure you want to delete the transaction?' +
+          (isReadyToBroadcast()
+            ? ' This action will require re-signing all transactions that were signed after this one in the sequence.'
+            : '')
+        }

frontend/src/store/features/multisig/multisigSlice.ts (2)

Line range hint 496-507: Consider enhancing error handling for sequence-related failures.

The current error handling captures general transaction signing errors, but consider adding specific handling for sequence-related failures:

1. Network errors during sequence retrieval
2. Sequence conflicts during broadcasting

Consider adding sequence-specific error types and handling:

 } catch (error: any) {
   trackEvent('MULTISIG', 'SIGN_TXN', FAILED);
   let errMsg =
     error?.message || 'Error while signing the transaction, Try again.';
   if (isNetworkError(errMsg)) {
     errMsg = `${NETWORK_ERROR}: ${errMsg}`;
   }
+  // Handle sequence-specific errors
+  if (error?.code === 'sequence_mismatch') {
+    errMsg = 'Transaction sequence mismatch. Please try again.';
+  }
   dispatch(
     setError({
       message: errMsg,
       type: 'error',
     })
   );

---

Line range hint 32-63: Consider enhancing state management for sequence tracking.

The current state management tracks transaction status but could benefit from tracking sequence-related states to improve user feedback and debugging:

Consider adding sequence-related state:

 const initialState: MultisigState = {
   signTransactionRes: {
     status: TxStatus.INIT,
     error: '',
+    sequence: {
+      current: 0,
+      pending: 0,
+      lastUpdated: null,
+    },
   },
   // ... rest of the state
 };

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Search for related sequence management logic
rg -t typescript -t javascript "signTransaction.*toBeBroadcastedCount" --no-heading

# Check for potential race conditions in sequence management
ast-grep --pattern 'signTransaction({ $$$, toBeBroadcastedCount $$$})'

#!/bin/bash
# Search for toBeBroadcastedCount usage and definition
rg -g '*.{ts,tsx,js,jsx}' 'toBeBroadcastedCount' -A 3

# Search for sequence management related state and reducers
rg -g '*.{ts,tsx,js,jsx}' 'signTransaction.*reducer|sequence.*reducer' -A 5

# Look for sequence validation logic
ast-grep --pattern 'function $name($$$) {
  $$$
  toBeBroadcastedCount
  $$$
}'

#!/bin/bash
# Search for getCount implementation and usage
rg -g '*.{ts,tsx,js,jsx}' 'getCount.*to-broadcast' -B 2 -A 5

# Look for sequence-related state management
rg -g '*.{ts,tsx,js,jsx}' 'sequence.*state|sequence.*slice' -B 2 -A 5

 if (isOverview) {
+  if (!chainName) {
+    dispatch(setError({ type: 'error', message: 'Chain name is required for navigation' }));
+    return;
+  }
-  router.push(`/multisig/${chainName}/${multisigAddress}`);
+  router.push(`/multisig/${chainName}/${multisigAddress}`).catch((error) => {
+    dispatch(setError({ type: 'error', message: 'Navigation failed' }));
+  });
 } else {
   broadcastTxn();
 }

#!/bin/bash
# Description: Check timestamp format consistency across the codebase

# Search for timestamp handling of these fields
rg -A 3 "last_updated|created_at|signed_at" --type ts

#!/bin/bash
# Check date utility function implementation
rg -A 5 "getTimeDifferenceToFutureDate" --type ts

# Check any API response handling or date formatting
rg -A 3 "new Date\(" --type ts

#!/bin/bash
# Check if signed_at is properly defined in types
rg -A 2 "interface Txn" 

#!/bin/bash
# Get the complete Txn interface definition
rg -A 20 "^interface Txn \{" frontend/src/types/multisig.d.ts

#!/bin/bash
# Check if signed_at is consistently set in the codebase
rg -A 2 "signed_at.*=" 

#!/bin/bash
# Search for signed_at in type definitions and interfaces
ast-grep --pattern 'type $_ = {
  $$$
  signed_at: $_
  $$$
}'

# Also check for signed_at in interfaces
ast-grep --pattern 'interface $_ {
  $$$
  signed_at: $_
  $$$
}'

# Look for assignments or mutations of signed_at
rg "signed_at.*=" -A 2

# Check actual usage of signed_at in components
rg "signed_at" -A 2 "frontend/src/app/(routes)/multisig"

sequence: multisigAcc?.sequence + toBeBroadcastedCount

#!/bin/bash
# Search for sequence-related code in the multisigSigning utility
ast-grep --pattern 'signTransaction($$$) {
  $$$
  sequence $$$
  $$$
}'

# Search for potential race conditions in sequence management
rg -A 5 'sequence.*=.*\+' 

#!/bin/bash
# Let's try a broader search for sequence-related code
rg -A 10 "toBeBroadcastedCount" 

# Search for sequence calculations in the multisig slice
rg -A 10 "sequence.*=" frontend/src/store/features/multisig/multisigSlice.ts

# Look for the signTransaction thunk implementation
ast-grep --pattern 'export const signTransaction = createAsyncThunk($$$)'